Suzy B Software 2

home *** CD-ROM | disk | FTP | other *** search

/ Suzy B Software 2 / Suzy B Software CD-ROM 2 (1994).iso / new_file / utilitys / mwind132 / mwind132.lzh / mauswind.eng < prev next >

Wrap

Text File | 1994-11-01 | 30.5 KB | 592 lines

Manual For Maus-Window V1.32 (as of 11/01/94) --------------------------------------------- 1. Maus-Window? --------------- People who have worked with X11 will have noticed that the active window is always the window located under the mouse-cursor (unless the window-manager has been configured otherwise). A similar behavior for ATARI-GEM would be nice, but unfortunately this can only be achieved by topping the window (or rewriting parts of the operating system). I found an article addressing this problem in a german magazine, but the methods described in there to automatically top a window all had serious disadvantages. So I decided to write a program to top windows myself, and the result is this accessory called Maus-Window. To install it, copy it to the root directory of the boot-drive. Maus-Window can also be used as a program, but this only makes sense in a multitasking- environment. Maus-Window has no problems running under MultiTOS, MagiC, and Geneva, as an accessory or an application. When Maus-Window is active and the mouse-cursor resides over a non- active window, the window will automatically be topped. This is achieved by simulating a mouse-click using the AES-call appl_tplay(). This confors to GEM and causes no problems with "clean" applications (see section 4 for a description of problematic programs). If the AES version number is >= 3.31, or if WINX >= 2.1 is installed, Maus-Window uses their extensions to find the owner of the affected window and then sends a WM_TOPPED-message to this application. When run under MultiTOS, Maus-Window additionally offers the possibility to raise the priority of the process with the topmost window. This allows more comfortable work. As of version 1.20, Maus-Window is bilingual, and thus has german and english dialogs. If the language of the computer running Maus-Window is not German, english dialogs will be used. If german dialogs are desired, install an _AKP-cookie (see: issue 4/93 German ST-Computer, Page 89) or (for MultiTOS users) set the AE_LANG environment variable. Falcon users can set the preferred language by using one of the NVRAM configuration utilities. This is the best method, since it will cause many other programs to show german text instead of english text as well. 2. Maus-Window Options ---------------------- When Maus-Window is activated (by selecting the entry in the desk- menu), it shows a dialog in a window. In the parameter-box some options may be set (and later saved) which affect the behaviour of Maus-Window. Any changes made here will immediatly take effect. The "OK"-Buttons is only used for finally accepting the new settings (similar to XCONTROL- modules). When Maus-Window is run as a program, you get this dialog by selecting the entry "Options: edit..." in the menu-bar. Maus-Window offers the following options: "Maus-Window active": Tells Maus-Window whether it should top windows or not. "work-area only": If this checkbox is crossed, windows will only be topped if the mouse- cursor is located in the work-area of a window. With WINX < 2.1, this option must be selected (since not having done so might cause window gadgets to be operated instead of topping the window). This option is also useful for WINX >= 2.1 or MultiTOS, because then it's easier to operate the gadgets of background windows (otherwise, it may come to pass that the affected window is topped before). "prevent 'disappearing'": Tells Maus-Window whether it should not top a window if it would completely cover the topmost window (or it's work-area, depeding on the setting of "work-area only"). "don't top during mouse-movement": If you do not want Maus-Window to top windows while the mouse is being moved, you should select this option. "delay: ..." This option will cause Maus-Window to wait a certain amount of time until it tops a window (that means, the mouse-cursor must have been over the window for that time). The duration of the delay is measured in ds (10th parts of a second) and can be selected by using the up and down arrow (either the arrows in the dialog or the cursor-keys). Use double-clicks to increase/ decrease the value by ten. "wait for mouse-movement": If this option is activated, Maus-Window will wait for a mouse-movement after the last change of the top-window. Example: Two windows are open, the mouse-cursor is in window #1, which is the topmost window. Now window #2 is topped through a keyboard action (like cycling windows). Without this option, Maus-Window will immediatly top window #1 again (which was obviously not the intention of the user). With this option active, Maus-Window will wait until the mouse is moved again, so window #2 will stay "on top". This option is also useful when using the backdrop-feature of MultiTOS or WINX. It is a good idea to also activate the option "don't top during mouse-movement". "protect windowless applications": When working in a multitasking-environment, changing the active window may also mean changing the active application and the menu-bar. Since it is possible that an active application has no window open (then there is no active window), changing to another application by topping one if its windows causes the program without windows to be "lost". That means, it can't be reactivated by clicking on a window. If you don't want this, use this option. It causes Maus-Window to check if the active application has one or more windows open before topping one of another program. If the AES support it, Maus-Window will also check if the window which is going to be topped belongs to an accessory. In that case, that window will be activated even when the active application has no own windows, since accessories don't have menu-bars and thus activating a window of an accessory doesn't affect the active menu. It is not possible to check whether an application has an own menu-bar or not, so this extra-feature only affects accessories. "Protect windowless applications" is only available if the AES allow more than one application (multitasking) and support the extended menu_bar-call. The extra-feature (option doesn't affect windows of accessories) will be used if the AES have the appl_search-function. Both calls are supported by MultiTOS, MagiC and Geneva. "higher priority for top-window": This option can only be used when running MultiTOS (Maus-Window also must have effective user ID 0, but this is only important for experts). If it is active, Maus-Window will automatically raise the priority of the process with the topmost window. The priority is reset to the old value if another process gets the top-window. "use mouse-click only": As described in section 4, with KAOS and/or NVDI 1.x it may come to pass that the mouse-cursor jumps to the left border of the screen when Maus-Window tops a window. This options removes the problem by only simulating a mouse-click. Normally, the mouse-cursor is first postiioned in such a way that the simulated click really hits the correct window. It is a good idea to also select the option "don't top during mouse-movement", because otherwise it may come to pass that during fast mouse-movement the simulated click hits the wrong window. "Use mouse-click only" cannot be selected when working with WINX >= 2.1 or AES >= 3.31, because in that case Maus-Window does not use a mouse- click to top a window. Additionally, it is possible to decide which "special-keys" (shift left/right, control, and alternate) prevent Maus-Window from topping windows (though holding down the mouse-buttons will always have this effect). To have the current settings as default, it is possible to save them in a file called MAUSWIND.INF. It should be located in the same directory as the program/accessory itself (it is searched with shel_find). On startup, Maus-Window looks for this file and uses the settings saved in it. If the file does not exist, all options are activated. The button "OK" replaces the current settings and closes the dialog. "Cancel" recalls the last settings and then quits the dialog. "Info" calls a window with some short information about Maus-Window. 3. Maus-Window "light" ---------------------- Since it seems to be necessary to have a "light"-version of every product, I did the same with Maus-Window. Maus-Window "light" is much shorter (only about 18% of the the size of the normal version), and offers no online-settings. It can only be used as an accessory. Maus-Window "light" also uses the file MAUSWIND.INF, but can only be set on and off (using and alert box that is shown when the entry under the Desk menu is selected). Thus, Maus-Window "light" is good for all people who only want to set the options once and then use the less memory-consuming version. 4. Problematic Programs ----------------------- As mentioned above, Maus-Window fully conforms to the GEM-conventions. It is necessary that the running applications follow these rules, too, though. For example, Maus-Window won't be able to top windows in programs which do not use real GEM-windows (Example: early versions of CyPress) or do not react to the AES-messages correctly. Moreover, there are programs which rely on certain behaviours of GEM which are not documentated, which can also cause problems. Unfortunately, Pure C 1.0 (it was used to develop Maus-Window) is one of them: When the help- system is called by pressing the Help key, Pure C opens a window. It may be that the mouse-cursor resides over another Pure C window at that moment, in which case Maus-Window will top it. Pure C ignores that and writes the output of the help-system directly into the topmost window. Additionally, the internal window-structure of Pure C gets confused, ending up in a loss of the sourecode in the topmost window. Pure C 1.1 shouldn't have this problem anymore, since the window-code has been improved. It is possible to avoid this problem by activating Maus- Window's option "wait for mouse-movement". If you recognize more programs that cause problems with Maus-Window, you should contact me (see section 5 for my address). I'm going to keep a list of these programs, which I will send to everyone who sends an envelope with his/her address and enough postage on it to cover mailing, or anyone who is able to receive email. Authors of problematic programs should think about recoding the corresponding parts of their work, because it's quite likely that these programs will cause problems with multitasking-environments or WINX, too. There are also problems with applications that allow the use of windowed dialogs lying in the background without having AES >= 4.0 or WINX >= 2.1. In that case, Maus-Window won't be able to top these windows, but will, in the worst case, operate one of the buttons of the windowed dialog. There's no way to solve that problem, you can only avoid it by using one of the shift-keys to prevent Maus-Window from trying to top such windows. Actually, this problem is due to a fault of the programmers of such applications, since they do not interpret the message that a window should be topped properly. When you are using programs that allow background-window-operation by using the extended features of newer AES-versions (WF_EVENT), Maus- Window will correctly top the windows, but you may sometimes find this annoying. In that case, you can also use one of the shift-keys to temporarily deactive Maus-Window. Some people told me that Maus-Window has problems with NVDI 1.x and/or KAOS-TOS. Instead of topping a window, the mouse-cursor only jumps to the left border of the screen. I really don't know why this happens, but I'm quite sure it's due to an error in the VDI-routines called by appl_tplay, because to make sure that the mouse-click hits the correct window, Maus-Window's appl_tplay-call also includes some mouse- positioning (this is legal!). To avoid this problems, I've included the option "use mouse-click only"; I can't tell if this really works (because I can't test it myself), but I'm quite sure it does. Another way to avoid this problem is using MultiTOS or WINX >= 2.1, because Maus-Window will then use a different method to top a window. Older versions of Mag!X 2.0 seem to have a problem with drawing drop- down-menus: Sometimes no wind_update(BEG_UPDATE) is called, so Maus- Window tops windows while a menu is active. Easy to imagine how this looks like... The new Mag!X (> 2.0, now called MagiC) shouldn't have this problem any longer. Some of my beta-testers also reported that it is impossible to run Maus-Window from within the \AUTO\APPS-folder. The strange thing is that this didn't happen to all of the MagiC-users. That also means that I can't make any reliable comments on this, so you have to try and see if it works... Geneva's "Tear-Away-Menu"-windows also cause problems: According to wind_get, they belong to the application they were torn off, but since the application doesn't know anything about the existence of these windows, it won't react to Maus-Window's WM_TOPPED-message correctly. The best what may happen is that the message is ignored (correct reaction) or the window's topped although it hasn't been opened by the application itself. The worst case is that the program hangs up, for example because it can't find the window in its internal window-list. Up to now, I've no idea how to solve this problem, maybe one of the Geneva-users out there has an idea? 5. Contacting The Author ------------------------ Everyone who wants to get the list of problematic programs or wants to make suggestions/bugreports should write to this address: Thomas Binder Johann-Valentin-May-Stra₧e 7 64665 Alsbach-Hähnlein Germany InterNet: binder@rbg.informatik.th-darmstadt.de IRC: Gryf If you think Maus-Window is worth a donnation, use this bank account (if you are able to transfer money to Germany from where you live): Dresdner Bank AG Frankfurt/Main Account-Nr. 9 024 050 00 BLZ 500 800 00 (I don't know if there is an equivilant to 'BLZ' in the english language) To be precise: I've already put a lot of work into Maus-Window, but I want to keep it being freely distributable. So it would be very nice if everyone who uses Maus-Window regularly would send a little donnation. This would also encourage me in making Maus-Window THE auto-window- topper for the ATARI. 6. How To Copy Maus-Window -------------------------- Maus-Window may still be freely distributed. The only condition is that all files (MAUSWIND.ACC, MWLIGHT.ACC, MAUSWIND.GER and MAUSWIND.ENG) are copied completely and unchanged (archiving is allowed). Spreading Maus-Window to bbs'es etc. is not only allowed, it's strongly encouraged! IMPORTANT: Use Maus-Window at your own risk! I do not undertake any responsibility for damages which occur after the correct or incorrect use of Maus-Window. 7. Plans For Future Versions ---------------------------- Up to now, only the priority of the MiniWin-process itself is raised, not the priority of the corresponding TOS-program. I hope to improve that soon (even when I have to work through /proc to do so...) That's all for the moment, maybe you have a good idea what I could improve. If so, please contact me (see section 5 for my address), I'll appreciate all useful suggestions... 8. Thanks & Greetings --------------------- Oh well, it seems I can't avoid that ;) I thank - dirch (Dirk Klemmt) for his POVShell, the basis for my idea of TOS2GEM, suggestions, bugreports, encouragements and the (sometimes senseless ;) IR-chats - rosebud (Uwe Seimet) for betatesting, suggestions, Diskus, help with my HD-problems and the IR-chats - moriati (Hider Aras) for betatesting and our IRC-"sessions" (hope I spelled the name correctly this time, sorry again for the typo!) - d_gently (Marcus Haebler) for his fileselector for MiNT (it gets better and better!) - chanel (Claus Brod) for his favourite music ;) and his help - AvAF30 (Arwin van Arum) for the great 8-channel-mods - Equinoxe (Harald Schönfeld) for the "professional" chats (do you think we'll ever make our screen-saver?) - jackintos (Ewald Seibert) and the others of the Acher & Eberl & Seibert GbR for BlowUP030 - _tfs_ (Thomas Schulze) for several MiNT-utilities and for beta-testing - Stfb (Stephane Boyeau) for beta-testing - X (Roland Schorr) for beta-tests, help, and procurements ;) - ki (Karsten Isakovic) for betatesting and his SysMon - RamaLama (Thorsten Schnurawa) for looking up things in his MagiC- manual (I know, it still says Mag!X on the cover :-P ) - Eric Smith for MiNT and answering my questions - Michel Forget for MasterBrowse, correcting this text, and his suggestions - My MagiC-betatesters Frank Bartels, Konrad Blum, Thomas Cloer, Dietmar Konermann, and Arno Welzel, ... - Arno Welzel again for his desktop "Thing", that will maybe soon support TOS2GEM, too - Andreas Kromke for his help on MagiC - ATARI for the Falcon - and some more, but I'm sure nobody will be interested in that... Greetings go to - dirch, rosebud, Equinoxe, d_gently, AvAF30, Apollo, moriati, chanel, jackintos, connect, MrSpock, Griff, Infinity, Spoil, julian, thorson, puujalka, kay_, _tfs_, TheFate, X, _uk_, daryl_, gsch, Stfb, Stealth_, Riker, Rhemie, Crac, MickMouse, Scrap, RamaLama, Steinpilz, NewMode, Anzaine, Mr_XY, LoST, Carnera, the-apple, ero, and the rest of #atari I've forgotten - DuffyDuck, swigert, mart, Hanni, HarryB and cbv, even though they sure won't ever read this... - the rest I've forgotten 9. Changes To Older Versions ---------------------------- Changes since V1.32₧: - Activating the menu-bar of an application when running MagiC now works again (a very embarrassing bug: I wrote appl_find("SCREENMGR") instead of appl_find("SCRENMGR"), maybe I was drunk when I did that...) - "Protect windowless applications" should now also work with the system-shell of MagiC (up to now, Maus-Window didn't detect correctly if the shell didn't have any open windows). - Using the right mouse-button to operate background-dialogs now works correctly (again) (I forgot to lock the mouse). - Sometimes the windowed dialogs didn't snap to a correct position, so the contents was a bit misplaced after the next redraw. This is fixed now. Changes since V1.31: - Maus-Window now correctly adjusts the USERDEF-text to the size of the system-font (because it's possible to change it with AES 4.1). A completely other system-font is not recognized yet, because there are some problems if it's a proportional font. - Maus-Window will not work if it's not possible to display at least 40x23 characters with the current system-font. - Clipping of USERDEF-objects now also works correctly if parts of them are off-screen. - The size of MAUSWIND.ACC has been reduced by about 1500 bytes, because I don't use the sprintf-function anymore. Changes since V1.31₧: - Should now also work correctly with Geneva. It seems that the Geneva- AES (still) have some problems you have to work around. Maybe this gets better one day... - When using MultiTOS with the option "higher priority for top-window", the priority is now raised by 40. Changes since V1.30₧: - New option "protect windowless applications", which takes care that no programs without open windows "get lost" in a multitasking- environment - Due to the new option, the old .INF-files can't be used any longer, so you have to set and save your preferences again. - When using MagiC, windows of accessories and programs without an own menu-bar were deactivated right after they were topped. This should be fixed now. - When you only have the info-dialog open, selecting the accessory- entry will bring up the parameter-window (up to now, you had to close the info-window first to do so) - Under MultiTOS, the priority of the screen-manager was raised, when there was no active window and the option "higher priority for top- window" was activated. This is fixed now. - Due to an error in the MiNTLibs, Maus-Window didn't raise the priority of processes which had a current priority < 0 (the GEMDOS- call Prenice usually returns a long, but the MiNTLibs declared it returning int). - It now shouldn't happen anymore that windows sometimes don't get topped when using MultiTOS. Changes since V1.29: - Fixed the following problems with MagiC (caused by MagiC, *not* by Maus-Window itself!): Adjusted wind_get-call to get topmost window (this causes the option "prevent 'disappearing'" to work correctly and Maus-Window to top even if there is no active topmost window) When a window is topped, now also the menu-bar of the affected application is activated. This is done by sending a special message to the screen-manager. A short comment: I'm really astonished at the fact that MagiC causes "clean" applications to work improperly because it has so much regards for older (not "clean") programs. This is not what I understand as "compatibilty". - Maus-Window's object-tree is now drawn a bit faster (mostly noticeable without NVDI...) - The frame of the windowed dialogs has been removed (this saves 2 pixels per direction ;) - Maus-Window now doesn't try to call wind_delete upon receiving the AC_CLOSED-message anymore (my documentation wasn't very precise in that case). Changes since V1.29₧: - The wind_get-call-error should now be really fixed - Some "cosmetic" changes... Changes since V1.28₧: - In sometimes happened that a wind_get-call failed (this was noticeable when using WINX). Should be removed now. - The option "delay" no longer is an alternative to "don't top during mouse-movement", both may be selected at the same time. In that case, a window will only be topped after the mouse-cursor hasn't moved for the given time. Changes since V1.27₧: - Maus-Window now has it's own menu-bar, when run as a program. So now it makes more sense to run it as a program (in a multitasking- environment, of course), because you don't have to keep the windows open. - When run as a program, Maus-Window now reacts to the AP_TERM-message and uses a real entry in the menu-bar (this is only important in connection with MultiTOS). Changes since V1.26: - New option "delay", thought as an alternative to "don't top during mouse-movement". If this option is activated, a window won't be topped until a certain amount of time (measured in 10th parts of a second) has passed. - Due to the new option, the format of the MAUSWIND.INF-file has changed, so you must set and save your preferences again (this always happens when new options are introduced, but I didn't mention that before). - Now compiled with MiNTLibs PL 44 (V1.26 used PL 42) - When the info-dialog is called, the parameter-window isn't closed any more (so both windows are on the screen at the same time) - All calls to graf_mkstate have been replaced by own routines, which internally use evnt_multi. This should remove some problems (especially when using Mag!X). Let's see... Changes since V1.25: - Maus-Window is now compiled using the MiNTLibs, unfortunately, this also leads to larger executables. The MiNTLibs do not set the MiNT- domain for accessories, so the improved path-handling will only show effect when Maus-Window is run as a program. Changes since V1.24₧: - "higher priotity for top-window" now doesn't try to get the "highest" priority any longer. Instead, the priority is raised by 20, and later reset to the old value. - "higher priority for top-window" in only selectable when Maus-Window has effective user ID 0 (with "normal" MultiTOS this should always be so). Changes since V1.23₧: - The option "work-area only" had its problems when the windows were not completely visible. This is fixed now. Changes since V1.22₧: - The windows of Maus-Window now are really non-modal, i.e, they now have a closer. - the window-dialogs aren't outlined any longer, this saves some space on the screen and is done by most programs. Changes since V1.21₧: - Introduction of the new option "wait for mouse-movement", which e.g. makes sure that after a change of the topmost window caused by keyboard-actions, Maus-Window won't top any window until the mouse is moved again. - The main-dialog has been thrown out, the parameter-dialog now appears first and offers a button to call the info-window. - Crossed and disabled check-boxes will now (hopefully) always be drawn correctly. Changes since V1.20₧: - Removed stupid bug when running with MultiTOS that caused a hangup of the whole system - Added option "higher priority for top-window" for MultiTOS Changes since V1.17: - Maus-Window now is bilingual, i.e., the dialogs and this text exist in German and English. The accessory automatically detects which language to use, for the manual, one has to choose the correct language oneself... - For users of KAOS/NVDI 1.x there now is the option "use mouse-click only", which should help against the problem that the mouse-cursor jumps to the left border of the screen instead of topping a window. Changes since V1.16: - The backdrop of MultiTOS and WINX is now supported, but normally, Maus-Window re-tops its windows immediately, if they are accessible. - If WINX >= 2.1 is installed, Maus-Window won't use mouse-clicks to top a window, but send a message to the owner of the window (as with MultiTOS). Thus, the button "work-area only" is no longer necessary for WINX >= 2.1 Changes since V1.15: - Keeping one of the special-keys (shift, control, or alternate) or the right mouse-button pressed when activating Maus-Window will call the parameter-dialog first. It is no good idea to use control for that, because MultiTOS will then remove the accessory... - With AES >= 3.31, Maus-Window no longer uses simulated mouse-clicks top a window. Instead, a new system call (wind_get with WF_OWNER) is used to inquire the owner of the window. A WM_TOPPED-message is then sent to this application. This has the advantage (especially when using MultiTOS), that one doesn't have to activate "work-area only" any longer. - Removed some problems with TOS 1.02: I called wind_update once to often which caused a hangup, and made the entry into the desk-menu too late, so it didn't appear in the desktop, first - The alert-Box of the "light"-version wasn't correct (I didn't recognize this at first, because I normally use LetEmFly, which corrected my fault automatically) Changes since V1.10 - The dialog-window is now splitted into three single windows: main- window, parameter-window and info-window. - Introduction of new options (prevent coverage of the topmost window, only top when mouse-cursor is still, prevent topping with shift, control, and/or alternate). - Introduction of Maus-Window "light", without online-setting of options, but with heavily reduced code-size. - Completely rewritten manual (but I still don't like it very much) Changes since V1.02: - Maus-Window has been completely rewritten. It now has a non-modal window for the settings which can also be operated with the keyboard. - Maus-Window also runs as a program, but this is only useful in a multitasking-environment. - It's now possible to choose, if, as introduced in version 1.02, a window is only topped when the mouse-cursor is located over the work- area of the window. - It's possible to save the settings of Maus-Window (on/off, work-area only yes/no) as a parameter-file which is read on startup Changes since V1.01: - Maus-Window only tops a window, if the mouse-cursor is located in the work-area (this prevents Maus-Window from operating the gadgets of background-windows when using WINX or MultiTOS) Changes since V1.00: - Maus-Window now waits a bit longer between two tests if a window has to be topped (so one has better chances to move over a background- window without topping it) - There have been (and still are) problems with the AES, which sometimes stop generating timer-events for Maus-Window. In that case, Maus-Window can't top any window (help: select Maus-Window's accessory-entry, after that, everything's fine again). I don't know why this happens, but I' quite sure it's due to a bug in the AES, since this doesn't happen with MultiTOS. Nevertheless, this problem now appears less often. Have fun with Maus-Window!